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We present a logical framework in which abstract interpretations can be naturally 
specified and then verified. Our approach is based on membership equational 
logic which extends equational logics by membership axioms, asserting that a 
term has a certain sort. We represent an abstract interpretation as a membership 
equational logic specification, usually as an overloaded order-sorted signature 
with membership axioms. It turns out that, for any term, its least sort over this 
specification corresponds to its most concrete abstract value. Maude implements 
membership equational logic and provides mechanisms to calculate the least sort 
of a term efficiently. We first show how Maude can be used to get prototyping of 
abstract interpretations “for free.” Building on the meta-logic facilities of Maude, 
we further develop a tool that automatically checks an abstract interpretation 
against a set of user-defined properties. This can be used to select an appropriate 
abstract interpretation, to characterize the specific loss of information during 
abstraction, and to compare different abstractions with each other. 
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Abstract. We present a logical framework in which abstract interpreta- 
tions can be naturally specified and then verified. Our approach is based 
on membership equational logic which extends equational logics by mem- 
bership axioms, asserting that a term has a certain sort. We represent 
an abstract interpretation as a membership equational logic specifica- 
tion, usually as an overloaded order-sorted signature with membership 
axioms. It turns out that, for any term, its least sort over this specifica- 
tion corresponds to its most concrete abstract value. Maude implements 
membership equational logic and provides mechanisms to calculate the 
least sort of a term efficiently. We first show how Maude can be used 
to get prototyping of abstract interpretations “for free.” Building on 
the meta-logic facilities of Maude, we further develop a tool that auto- 
matically checks an abstract interpretation against a set of user-defined 
properties. This can be used to select an appropriate abstract interpreta- 
tion, to characterize the specific loss of information during abstraction, 
and to compare different abstractions with each other. 


1 Introduction 

Abstract interpretation [5] has become a unifying framework for a variety of 
program analysis techniques. It is also increasingly finding application in other 
areas of computer science, e.g., model checking [2, 13] and theorem proving [12]. 
Its appeal is precisely the involved abstraction which simplifies calculation and 
search, thus allowing us to efficiently find approximate but correct solutions to 
problems which may otherwise be too hard. 

In practice, however, finding the right abstraction for a problem at hand is 
often all but trivial. Different abstractions offer different trade-offs between effi- 
ciency and approximation which can often be validated and evaluated only with 
a prototype implementation of the abstract interpretation. A more definitive 
evaluation of the abstraction, e.g., in the form of a correctness or completeness 
proof, even requires support for formal verification. 

In this paper, we are addressing these validation and verification issues. We 
show how abstract interpretation can be specified and interpreted in membership 
equational logic (MEL) [11,1], an expressive logic which generalizes the various 



forms of equational logics used in algebraic specification techniques. With this 
re-interpretation, we can use the Maude system [4, 3] as environment to execute 
the specification of an abstraction, or in other words, we get a prototyping envi- 
ronment “for free.” We further developed a tool which uses Maude’s meta-logic 
capabilities to verify abstract interpretations against properties that are also 
specified as MEL sentences. More precisely, we provide a Maude module that 
allows us to write commands like 

Maude> reduce verify PROPERTIES on ABSTRACTION . 

where ABSTRACTION is a specification of an abstract interpretation and PROPERTIES 
is another MEL specification. verify_on_ returns a list of warnings showing all 
sentences in PROPERTIES that are violated by the abstract interpretation, together 
with (abstract) counterexamples. We can see at this stage three applications of 
such a tool, depending on what the specification PROPERTIES actually represents: 

— If PROPERTIES is a set of desired properties an abstract interpretation should 
have in order to be employed in a certain context, then we can use our tool 
to retrieve from a library abstract interpretations that satisfy them; 

— If PROPERTIES is an axiomatic presentation of the concrete domain, then we 
can use the tool to see how much and what kind of information the abstrac- 
tion looses and then decide if it is acceptable or not for a specific task; 

— If PROPERTIES is another abstract interpretation of the same concrete domain, 
then an empty list of warnings means that ABSTRACTION refines this second 
abstraction. 

The basic idea of our approach is relatively straightforward. If we think of an 
abstract interpretation as a lattice, then a sort is associated to each node in the 
lattice and a subsort is associated to each edge. The tables defining the abstract 
operations are replaced by a series of overloaded operators, while properties that 
cannot be captured by tables are declared via MEL sentences, e.g., 

sorts Bottom Neg Pos Real . 
subsorts Bottom < Neg Pos < Real . 
op _+_ : Neg Neg -> Neg . 

op _+_ : Pos Pos -> Pos . 

op : Neg Pos -> Neg . 

op : Neg Neg -> Pos . 

op _/_ : Real Real -> Real . 
op _/_ : Real Zero -> Bottom . 
mb X / X : Pos -one . 

is a fragment of the usual sign abstraction.^ The abstract value of an expression 
over the concrete domain then corresponds to its least sort over the specified 
signature; an efficient automatic least sort calculation is provided by Maude. 

Our approach to abstract interpretation in MEL is more logic-oriented than 
the usual lattice-oriented approach. We advocate a loose semantics for the spec- 
ifications corresponding to abstract interpretations. The intended abstract in- 
terpretation is then just one model of the specification, namely that one that 

^ The precise formalism used here will be explained later. 



adds exactly one new element to each carrier, besides those resulting from the 
inclusion of carriers required by the subsort declarations. Another model is the 
one that structures the concrete domain into subsets of elements of the same 
“type” . This model is thus similar to the powerset construction usually used as 
concrete domain in the lattice-oriented approach. 

The ultimate goal of abstract interpretations is to simplify reasoning about 
the concrete domain. We thus prefer to add to the specification as many sentences 
that are valid properties of the concrete domain as needed rather than to add 
exactly those that make the intended abstract interpretation an initial model. 
Our approach requires no structure on the concrete domain and the abstract 
domain need not be a complete lattice or even a lower semilattice. Instead, 
the associated specification is expected to be regular [1] in order for Maude to 
correctly compute the least sort of a term. Interestingly, the fact that the partial 
order on sorts is a lattice tends to be sufficient for regularity in practice. 

Our work here represents only first steps towards a full re-interpretation of 
abstract interpretations in MEL. Our approach is currently restricted to finite 
number of sorts, or abstract types, and we cannot yet handle fixpoint operators. 
These restrictions will be subject to further investigation. The focus of this paper 
is on the tool aspects rather than on the theoretical aspects. 

The remainder of the paper is organized as follows. In the next section we 
briefly introduce the fundamental notions and notations of membership equa- 
tional logic and the Maude-system, as far as they are required for our purposes. 
We then show in Section 3 how abstract interpretations can be seen as mem- 
bership algebras. Section 4 shows how a MEL specification can be associated to 
an abstract interpretation and how abstract types can be automatically calcu- 
lated at the level of that specification. Section 5 finally discusses how abstract 
interpretations can be verified in the framework proposed in this paper. 

2 Membership Equational Logic and Maude 

Membership equational logic [11, 1] extends many-sorted equational logic [8] with 
membership assertions t : s stating that a term t belongs to a sort s. It subsumes 
a wide variety of specification formalisms, including order-sorted [7, 9] and partial 
equational logics. Despite its generality, it still enjoys the good properties of 
equational logics: it is simple, efficiently implementable, and admits sound and 
complete deduction as well as free models. In this section we informally present 
membership equational logic and some of the notational conventions used in 
Maude, referring to [11,1,4,3] for a comprehensive exposition. We assume a 
basic familiarity with many-sorted equational logic. 

In membership equational logic, the sorts are grouped in clusters or kinds 
and the operations are only defined on these clusters. A signature f2 consists of 
a set S of sorts, a set K of kinds, a map n:S^K, and a K* x i^-indexed set 
S = {Sw,k I (w,k) G K* X K} of operations. An J7-algebra is a A-algebra A 
together with a subset Ag C Ak for each k £ K and each s G n^^{k). Eor any 
i^-indexed set of variables X, Tjj{X) denotes the usual {K, Aj-algebra of terms. 



The sentences of MEL generalize the conditional equations (VX) t = t' if C 
of equational logics by allowing membership assertions. They are universally 
quantified Horn clauses of the form 


(VX) tisifC 


In both cases, the condition C is a finite set {ui = vi, ...,Un = Vn,ti : si, '■ 
Sm} and t,t' ,ti, ...,Un,Vn are terms in Tjj{X). If n = m = 0 then 

the sentence is called unconditional or atomic. 

We discuss only satisfaction of atomic sentences in this paragraph; the general 
case follows easily. For an J7-algebra A and an assignment a:X — ^ we use 
a*:Tjj{X) — >• A to denote the unique extension of a to a morphism of {K,S)- 
algebras. We then say that A satisfies (VX) t = t' (or (VX) t : s) if and only if 
for each assignment a we also have that a*{t) = a*{t') (or a*{t) G ^s). A MEL 
specification or theory is a pair {f2,r), where T is a set of J7-sentences, and it 
defines a class of J7-algebras (those that satisfy it) denoted Alg^j^ j.). 

The MEL proof theory is derived from the standard proof theory of equa- 
tional logic. Its distinctive characteristic is that it allows to infer the member- 
ships of terms to sorts in addition to the standard equalities of terms. Given a 
specification (17, T), there are two inference rules that facilitate that. One is a 
modification of the modus ponens rule of equational logic to deduce a member- 
ship from a (conditional) sentence in F once its condition has been proven. The 
second rule is an extensionality rule over sorts which asserts that equal terms 
have the same sort. 


Membership: 


r (VX) t = t' r\-n (VX) t ■. s 
r h (VX) t' : s 


Maude [4,3] is a high-performance rewrite system in the OBJ family [10] 
that supports both membership equational logic and rewriting logic. Its current 
version processes up to 3 million rewritings per second on standard hardware. 
We use Maude notation in this paper not only to represent abstract interpreta- 
tions in membership equational logic but also to verify them. A few notational 
conventions are introduced next. Equations and conditional equations are de- 
clared via the keywords eq and ceq, respectively; membership and conditional 
membership assertions are declared via the keywords mb and cmb. Operations 
can be declared using mix-fix notation. They can also be overloaded; however, 
this is only syntactic sugar for appropriate conditional membership assertions. 
For example, : Pos Neg -> Meg can be replaced by cmb X * Y : Meg if X : 
Pos and Y : Meg, where is defined on appropriate kinds. Declarations of the 
form var X : S are used to introduce variables; their scope is bounded by the 
enclosing module, introduced by fmod . . . end. Kinds need not to be declared 
explicitly. They are automatically calculated as the connected components of 
the partial order defined by subsort declarations. 

A typical problem of specification formalisms that allow order-sorting and 
operator overloading is that some terms may have various correct sorts in the 
same time. The possible sorts of a term can be deduced using the complete 



deduction system of MEL, i.e., sorts{t) is the set {s G 5 | E (VX) t : s}. 
A specification (J7,E) is called regular if and only if for each term t, sorts{t) 
is either empty or has a minimal element wrt the subsort relation. A detailed 
discussion on regularity can be found in [1], together with decidability results 
and various syntactic criteria that imply regularity. Maude implements some of 
these criteria. We can thus assume that each valid specification is regular and 
that we can calculate the least sort of any term efficiently. 


3 Abstract Interpretations as 17-Algebras 

To illustrate our approach, we describe a generalized sign/range abstraction for 
the real numbers. This interpretation is a simplified version of a more complex 
one that we implemented in a program synthesis system for the statistical data 
analysis domain [6]. In this domain, probabilities (i.e., the interval [0,1]) and 
thus the real numbers “0” and “1” are of specific interest. In order to handle 
division by zero appropriately, we need to make an assumption about the real 
numbers. We can consider division either as a partial function and leave the set 
of real numbers unchanged, or as a total function, in which case we need to add a 
new element to the real numbers which represents undefinedness. For simplicity, 
we choose the second assumption; note that MEL also supports partiality, so 
our choice does not reflect a limitation of the framework. Let T be the special 
symbol denoting “undefined”; we use the same symbol T for the set {T}, and let 
M± denote the set of real numbers plus T. The abstract domain then consists 
of eleven intervals of M± which are partially ordered by inclusion. Each interval 
of real numbers also contains T, reflecting the intuition that the result of an 
expression can be either a number within that interval or undefined. This domain 
can, as usual, be represented by the following lattice: 


(— oo, +oo)x 



( — oo, — l]x [— l,0]x [0,+l]x [+l,+oo)x 





We can now provide the abstract versions of operations. The typical, concise 
way to do it is by tables, as for example the following table for division^: 


^ For typographical reasons we omit the T-subscript here. 



XfY 

(—00, 00) 

(-00, 0 ] 

[ 0 , 00) 

- 1 ] 

[- 1 , 0 ] 

[ 0 ,+l] 

[+ 1 , 00) 

-1 

0 

+1 

J. 

(—00,00) 

(— 00 , 00 ) 

( — 00, 00) 

( — 00 , 00 ) 

(— 00 , 00 ) 

( — 00, 00) 

( — 00, 00) 

( — 00, 00) 

(— 00 , 00 ) 

J. 

( — 00 , 00 ) 

J. 

(-00, 0 ] 

(—00, 00) 

[ 0 , 00) 

(-00, 0 ] 

[ 0 , 00) 

[ 0 , 00) 

(-00, 0 ] 

(-00, 0 ] 

[ 0 , 00) 

J. 

(-00, 0 ] 

J. 

[ 0 , 00) 

(—00, 00) 

(-00, 0 ] 

[ 0 , 00) 

(-00, 0 ] 

(-00, 0 ] 

[ 0 , 00) 

[ 0 , 00) 

(-00, 0 ] 

J. 

[ 0 , 00) 

J. 

(-00, - 1 ] 

(—00, 00) 

[ 0 , 00) 

(-00, 0 ] 

[ 0 , 00) 

[+ 1 , 00) 

(-^, - 1 ] 

(-00, 0 ] 

(+ 1 , 00] 

J. 

(-^, - 1 ] 

J. 

[- 1 , 0 ] 

(—00, 00) 

[ 0 , 00) 

(-00, 0 ] 

[ 0 , + 1 ] 

[ 0 , 00) 

(-00, 0 ] 

[- 1 , 0 ] 

[ 0 ,+l] 

J. 

[- 1 , 0 ] 

J. 

[ 0 , + 1 ] 

(—00, 00) 

(-00, 0 ] 

[ 0 , 00) 

[- 1 , 0 ] 

(-00, 0 ] 

[ 0 , 00) 

[ 0 , + 1 ] 

[- 1 , 0 ] 

J. 

[ 0 ,+l] 

J. 

[+ 1 , 00) 

(—00, 00) 

(-00, 0 ] 

[ 0 , 00) 

(-00, 0 ] 

(-^, - 1 ] 

[+ 1 , 00) 

[ 0 , 00) 

(-^, - 1 ] 

J. 

[+ 1 , 00) 

J. 

-1 

(— 00 , 00 ) 

[ 0 , 00) 

(-00, 0 ] 

[ 0 , + 1 ] 

[+ 1 , 00) 

(-^, - 1 ] 

[- 1 , 0 ] 

+1 

J. 

-1 

J. 

0 

0 

0 

0 

0 

0 

0 

0 

0 

J. 

0 

J. 

+1 

(— 00 , 00 ) 

(-00, 0 ] 

[ 0 , 00) 

[- 1 , 0 ] 

(-^, - 1 ] 

[+ 1 , 00) 

[ 0 , + 1 ] 

-1 

J. 

+1 

J. 

J. 

J. 

J. 

J. 

J. 

J. 

J. 

J. 

J. 

J. 

J. 

J. 


However, it is known that tables are often not sufficient to fully describe the 
intended behavior of abstract operations. For example, there is no possibility to 
specify that the abstract value of X/X is +lj_. Hence, the abstraction becomes 
less precise than one may wish. We will show in the next section how MEL allows 
us to use membership assertions to specify such properties. 

In the context of MEL, it is more convenient to regard the lattice and the ta- 
bles associated with an abstract interpretation as an J7-algebra over an appropri- 
ate signature This general algebraic view gives us the freedom to consider an 
abstract interpretation as “just one particular model” of an (J7, E)-specification. 
Since a specification can have many different models, this allows us also to relate 
different abstractions to each other. In the remainder of this section we concen- 
trate on showing how abstract interpretations can be seen as J7-algebras. In the 
next sections we will then show how a MEL specification can naturally be asso- 
ciated with an intended abstract interpretation and how we can prove properties 
at the level of that specification rather than at the level of the abstract model. 

The lattice actually gives some structure to the originally fiat concrete do- 
main of real numbers. It is now natural to associate a MEL-signature to the 
lattice above by providing a sort for each node in the lattice and using subsort 
relations to reflect the lattice structure. In Maude, this is represented as: 


Real 

= 

(— 00 , -Poo) 

Meg 

= 

(- 00 , Ojj. 

Meg-1 

— = 

(- 00 , -Ijj. 

Meg-s 

— = 

[-1, 0]x 

Meg-one 

= 

-lx 

Pos 

= 

[0, -|-oo)j. 

Pos-1 

= 

[-pl, -pOo)x 

Pos-s 

— = 

[0, +l]x 

Pos-one 

= 

-p lx 

Zero 

= 

Ox 

Bottom . 

= 

T 


subsorts Neg Pos < Real . 
subsorts Meg-one < Meg-1 Meg-s < Meg . 
subsorts Pos-one < Pos-s Pos-1 < Pos . 
subsorts Zero < Meg-s Pos-s . 
subsorts Bottom < Meg-one Zero Pos-one . 



Since the lattice is a single connected component, all sorts belong to the same 
kind k and all operations are declared on that kind, i.e., we have : 

k X k ^ k and — : fc — >• fc, or again using the Maude notation, 

ops : Real Real -> Real . 

op : Real -> Real . 

Now, the extended real numbers M± can be viewed as an J7-algebra A as follows. 
For each sort s we define as its carrier Ag the appropriate subset of R±. For 
example, we define A^ = ^Real = ^Pos = = {a; G iR | x > 0 or x = ±} 

and so on, until we get to ^Bottom = {-*-}■ operations are the usual arithmetic 
operations on M±. Notice that most of the carriers are infinite sets. 

However, A is not the only interesting J7-algebra we can construct. Instead 
of using the set of the real numbers within the respective intervals as carrier we 
can as well use the intervals themselves. We thus get ^Bottom = -^Bottom = {-*-} 
and ^Pos“one — .^Pos“one — {d"l,-L} but I^Pos—s — {[0; d”f]; 0; d”f ; -f and 
.Bpos-s = {[+!) +oo], +1, -L} and so on. Hence, B’s carrier Bk is finite — in fact, 
it consists of exactly the same eleven elements as the lattice. H’s operations are 
defined via operator tables, as for example the division table. 

The main difference between the two J7-algebras A and B above is obviously 
that B is finite. Hence, it is easy to handle in practice but it looses information 
about the concrete domain of real numbers, so that many useful properties of 
real numbers do not hold anymore. A just structures the flat concrete domain 
but still carries all the burden of analyzing the real numbers directly. Ideally, we 
would want to keep both algebras, as opposed to just discard A and keep B as it 
often happens in practice. We next show that MEL is a framework under which 
we can write a (finite) specification which accepts both A and B as models. This 
specification can be seen as a “finite abstraction” of the concrete domain that 
can contain as many properties of the domain as needed. 

4 Interpreting Abstract Interpretations 

We present our technique on the example in the previous section. We start in 
Maude with a module ABSTRACTION-REAL by defining the abstract domain as a 
partial order via sorts and subsorts: 

fmod ABSTRACTION-REAL is 

sorts Real Neg Pos Neg-I Pos-I Neg-s Pos-s 
Neg-one Zero Pos-one Bottom . 
subsorts Neg-one < Neg-I Neg-s < Neg < Real . 
subsorts Zero < Neg-s Pos-s . 
subsorts Pos-one < Pos-s Pos-I < Pos < Real . 
subsorts Bottom < Neg-one Zero Pos-one . 

Note that we can declare more than one subsort in a subsorts declaration; a sort 
is smaller than any other sort occurring between any subsequent < symbol and 
the next period. The concrete real numbers will be provided in Maude 2.0 in a 



module MACHINE-REAL. This module is imported by the abstract interpretation 
using the protecting MACHINE-REAL clause; the reals are abstracted via a map I _l 
: MachineReal -> Real defined using membership assertions: 


protecting MACHINE-REAL . 
op I _ I : MachineReal -> Real . 
var R : MachineReal . 
mb I 0 I : Zero . 

mb 111: Pos-one . 
mb I -1 I : Neg-one . 
cmb I R I : Neg-I if R <= -1 . 

cmb I R I : Neg-s if R >= -1 and R <= 0 . 

cmb I R I : Pos-s if R >= 0 and R <= 1 . 

cmb I R I : Pos-I if R >= 1 . 

Note that I 0 I , the abstraction of 0, can be of three sorts: Zero, Neg-s and 
Pos-s. However, Maude automatically calculates for each term its smallest sort, 
so I 0 I has the sort Zero. 

The next step is to abstract the operations defined on the concrete domain, 
in our case addition, multiplication, negation, subtraction and division. We do 
this by making intensive use of operator overloading, which basically represents 
an elegant way to encode the tables often used to define abstract interpretations: 

op _+_ : Bottom Real -> Bottom . op : Bottom Real -> Bottom . 

op _+_ : Real Bottom -> Bottom . op : Real Bottom -> Bottom . 

op _+_ : Neg-one Zero -> Neg-one . op : Neg-one Pos-one -> Neg-one . 

op _+_ : Zero Neg-one -> Neg-one . op : Pos-one Neg-one -> Neg-one . 

op _+_ : Zero Zero -> Zero . op : Real Zero -> Zero . 

op _+_ : Neg-one Pos-one -> Zero . op : Zero Real -> Zero . 

op _+_ : Pos-one Neg-one -> Zero . op : Pos-one Pos-one -> Pos-one . 

op _+_ : Pos-one Zero -> Pos-one . op : Neg-one Neg-one -> Pos-one . 

op _+_ : Zero Pos-one -> Pos-one . op : Neg-I Pos-I -> Neg-I . 

op _+_ : Neg-I Neg -> Neg-I . op : Pos-I Neg-I -> Neg-I . 

op _+_ : Neg Neg-I -> Neg-I . op : Neg-s Pos-s -> Neg-s . 

op _+_ : Neg-s Zero -> Neg-s . op : Pos-s Neg-s -> Neg-s . 

op _+_ : Zero Neg-s -> Neg-s . op : Pos-s Pos-s -> Pos-s . 

op _+_ : Pos-s Zero -> Pos-s . op : Neg-s Neg-s -> Pos-s . 

op _+_ : Zero Pos-s -> Pos-s . op : Neg-I Neg-I -> Pos-I . 

op _+_ : Pos-I Pos -> Pos-I . op : Pos-I Pos-I -> Pos-I . 

op _+_ : Pos Pos-I -> Pos-I . op : Neg Pos -> Neg . 

op _+_ : Neg Neg -> Neg . op : Pos Neg -> Neg . 

op _+_ : Neg-I Pos-s -> Neg . op : Pos Pos -> Pos . 

op _+_ : Pos-s Neg-I -> Neg . op : Neg Neg -> Pos . 

op _+_ : Pos Pos -> Pos . op : Real Real -> Real . 

op _+_ : Pos-I Neg-s -> Pos . 

op _+_ : Neg-s Pos-I -> Pos . 

op _+_ : Real Real -> Real . 

In this case, we are able to define the intended abstractions of addition and 
multiplication completely by operator overloading (i.e., in table form). In prac- 



tice, however, tables are often not sufficient to properly define abstract versions 
of operators. Some important domain specific properties of operators cannot be 
specified only looking at the abstract type of their arguments. For example, there 
is no way to declare that the abstract type of x/x is Pos-one by just analyzing 
the arity (or the table) of (the abstraction of) division. Fortunately, membership 
equational logic allows us to declare membership assertions, which then can be 
used to infer the smallest type of an abstract term: 


op 


Bottom -> Bottom . 

op 


Bottom Real -> 

Bottom . 

op 

“ _ 

Pos-one -> Neg-one . 

op 


Real Zero -> Bottom . 

op 


Zero -> Zero . 

op 


Neg-one Pos-one 

-> Neg-one 

op 

“ _ 

Neg-one -> Pos-one . 

op 


Pos-one Neg-one 

-> Neg-one 

op 


Pos-1 -> Neg-1 . 

op 


Zero Real -> Zero . 

op 


Pos-s -> Neg-s . 

op 


Pos-one Pos-one 

-> Pos-one 

op 


Neg-s -> Pos-s . 

op 


Neg-one Neg-one 

-> Pos-one 

op 


Neg-1 -> Pos-1 . 

op 


Neg-1 Pos-s -> 

Neg-1 . 

op 


Pos -> Neg . 

op 


Pos-1 Neg-s -> 

Neg-1 . 

op 


Neg -> Pos . 

op 


Neg-s Pos-1 -> 

Neg-s . 

op 


Real -> Real . 

op 


Pos-s Neg-1 -> 

Neg-s . 




op 


Pos-s Pos-1 -> 

Pos-s . 

vars X 

Y : Real . 

op 


Neg-s Neg-1 -> 

Pos-s . 




op 


Neg-1 Neg-s -> 

Pos-1 . 

mb 

X + 

(- X) : Zero . 

op 


Pos-1 Pos-s -> 

Pos-1 . 




op 


Neg Pos -> Neg 


op 


: Real Real -> Real . 

op 


Pos Neg -> Neg 


eq 

X - 

Y = X + (- Y) . 

op 


Neg Neg -> Pos 





op 


Pos Pos -> Pos 





op 


Real Real -> Real . 




mb 

X / X : Pos-one . 



mb (- X) / X : Neg-one . 
endfm 

Notice that we can use the equation “eq X - Y = X + (- Y) .’’to eliminate the 
abstract subtraction in a way consistent with its concrete definition, thus reduc- 
ing the size of the specification. 

It may be worth mentioning here that Maude provides internal algorithms to 
insure the regularity of a signature and that it warned us a few times while testing 
the overloaded signature above that the signature was not regular. After careful 
examination, we discovered that our “table” was not consistent, in the sense 
that certain concrete expressions couldn’t have a most precise abstract value. 
For example, we forgot to add the third declaration of then Maude issued a 
warning saying that the regularity check failed: indeed, the product of negative 
one and positive one could have any sort in the set {Meg-s,Neg-l,Neg,Real}, but 
this set has no minimal element. The regularity checks thus helped us cover all 
the situations. We strongly believe that there is a deep relationship between 
the regularity of order-sorted overloaded signatures and the existence of most 



concrete abstract values for abstract interpretations where the abstract values 
form a lattice, and that this relationship is worth investigating. 

The module above can now be used as a decision procedure to abstract 
expressions. The following are a few examples showing how it works: 

red I 1 - 1 I . red I 2 - 2 I . 

red I 1 I - I 1 I . red I 2 I - I 2 I . red I 1 I + I -1 I . 

red I 2 I + I -2 I . 
red (I -1 I + I 1 I) + I 1 I . 
red I -1 I + (I 1 I + I 1 I) . 

red I -2 I / (I 3 I / I 3 I) . 

red (I -2 I * I 3 I) / I 3 I . 

The first five expressions are all correctly abstracted to Zero; that is, they all 
reduce to terms of sort Zero, but for different reasons: the first two reduce to 
I 0 I whose sort is Zero, the next two first use the equation eq X - Y = X + (- 
Y) to eliminate the subtraction and then use the membership assertion mb X + 
(- X) : Zero, and the last one first calculates the sorts of I 1 I and I -1 I and 
then use the declaration op _+_ : Pos-one Meg-one -> Zero. The following is the 
Maude output for the other five reductions: 

result Real: I 2 I + I -2 I 
result Pos-one: (|-1|+|1|)+|1| 
result Pos: |-1|+(|1|+|1|) 
result Meg-1: I -2 I / ( I 3 I / I 3 I ) 
result Meg: (|-2|*|3|)/|3| 

The reductions above reflect the intuition that abstract interpretations loose 
information. For example, since the most specific abstract values of 2 and -2 
are Pos-l and Meg-l, respectively, we cannot say anything about the abstract 
type of I 2 I + I -2 I , so the returned type is Real. The next two reductions 
show that the abstraction of addition is not associative anymore, which was an 
unexpected problem that we encountered in our data analysis synthesis system. 
Finally, the last two reductions show that other expected equational properties 
of the concrete domain do not hold at the abstract level either, in this case the 
equation eq X / (Y / Z) = (X * Z) / Y. 

5 Proving Properties about Abstract Interpretations 

Since by abstraction of a concrete domain one actually looses information, a 
natural and important question is “how much information is lost?”. This is a 
difficult question both to ask and to answer, and probably new theoretical re- 
sults are behind it; instead of pursuing theoretical research, we decided to take 
a pragmatic attitude and develop an environment in which one can test an ab- 
stract interpretation as a Maude module for various equational or membership 
properties that it is expected or not to satisfy. For example, suppose that one 
considers the following properties (also written as a Maude module): 



fmod PROPERTIES is 
sorts Pos Neg Real . 
subsorts Pos Meg < Real . 
op : Real -> Real . 

ops (_+_) (_*_) (_/_) : Real Real -> Real . 

vars X Y Z : Real . 


eq 

X + Y = Y + 

X 




true 

eq 

X * Y = Y * 

X 




true 

eq 

X + (Y + Z) 

= 

(X + Y) + Z , 



false 

eq 

X * (Y * Z) 

= 

(X * Y) * Z , 



true 

eq 

X * (Y + Z) 

= 

(X * Y) + (X 

* Z) . 


false 

eq 

- (- X) = X 





true 

eq 

X * (- Y) = 

- 

(X * Y) . 



true 

eq 

(- X) / Y = 

- 

(X / Y) . 



true 

eq 

(X / Y) / Z 

= 

X / (Y * Z) , 



true 

eq 

X / (Y / Z) 

= 

(X * Z) / Y , 



false 

eq 

(X + Y) / Z 

= 

(X / Z) + (Y 

/ Z) . 


false 

eq 

X * X = X * 

X 

* X * X . 



true 

mb 

X * X : Pos 





true 

mb 

((X * X) + 

(Y 

* Y)) + (X * 

Y) : Pos . 


false 

mb 

(X - Y) * (Y - 

- X) : Meg . 



false 

endfm 







All one needs to know in order to write up desired properties of an abstract 
interpretation are the sorts and the operations one wants to refer to. Notice that 
the sorts Pos and Meg are only needed for the last three properties, so one could 
remove them if one was not interested in the membership properties. The fact 
that the main sort Real has 10 subsorts in our previous abstract interpretation 
is part of the abstraction, not of its desired properties wrt the concrete domain. 
Since one may want to test the same properties against many different abstract 
interpretations of the same domain and to chose one that best fits one’s purpose, 
one should refer to as few sorts specific to only one abstraction as possible when 
writing properties. 

One can now test the properties above against the abstract interpretation 
presented in the previous section using a simple command: 

red verify PROPERTIES on ABSTRACTIOM-REAL . 

after first loading the module which defines the operation verify_on_ and its se- 
mantics, whose implementation is briefly presented in the appendix. The {true, 
false} comments in the module above summarize the execution of this command. 
In fact, for each of the properties above, Maude detected all counterexamples 
(possible abstract values for X, Y, z) that violated it (780 in total). For exam- 
ple, the associativity of addition doesn’t hold when X : Meg-one, Y : Pos-one, z 
: Pos-one, and the last membership assertion doesn’t hold when X ; Pos-one, Y 
: Pos, Z ; Zero. Interestingly, notice the last equation holds for the presented 
abstract interpretation, even if it doesn’t hold for the concrete domain of real 



numbers. The lesson that we learned from experiments with this system is that 
the loss of information due to an abstraction is reflected not only by lost prop- 
erties of the concrete domain, but also by properties the abstraction has that 
don’t hold in the concrete domain. 

The meta level of Maude was needed to implement the above environment, 
that is, the functionality of the operation verify_on_. At the meta level, the mod- 
ules are just terms of sort FModule, so verify_on_ has the arity FModule FModule 
-> Warnings, where Warnings stays for a list of warnings. In our current imple- 
mentation, we traverse the first fmodule and for each equation or membership 
assertion, we take the second fmodule and generate all possible abstract sorts 
for variables and then calculate the least sorts of the terms involved (two terms 
if the statement is an equation and one if it’s a membership). If the statement is 
an equation then we output a warning if and only if the two terms have different 
least sorts, and if the statement is a membership assertion then a warning is 
output if and only if the calculated least sort is not smaller than or equal to the 
sort specified in the membership statement. The interested reader may consult 
the appendix for more detail on the implementation. 

The presented tool is still in an experimentation stage. One of our major 
goals was to keep it simple and flexible, such that to easily adapt it for concrete 
uses. We can currently foresee three applications of this tool, depending on what 
the specification PROPERTIES is: 

Abstract interpretation retrieval. If it is a collection of required properties 
manually or automatically generated in the context of a concrete situation 
where an abstract interpretation is needed, then one can use our tool to au- 
tomatically retrieve from a library those abstract interpretations that satisfy 
the requirements; 

Comparison with the concrete domain. If it is an axiomatic presentation 
of the concrete domain, such as a Peano specification of natural numbers, 
then one can use the tool to understand or test how much and what kind of 
information a certain abstract interpretation looses and then decide whether 
it is acceptable or not for a specific task; 

Abstract interpretation refinement. If it is another abstract interpretation 
of the same concrete domain, then an empty list of warnings means that 
ABSTRACTION refines this second abstraction. 

6 Conclusion and Future Work 

We presented a new way to represent and verify abstract interpretations. We ab- 
stracted a concrete domain by a finite membership equational logic specification, 
which, under loose semantics, also admits as model the common abstract inter- 
pretations whose abstract values form a lattice and whose abstract operations 
are given by a table. This flexible framework allows one to add needed proper- 
ties of the concrete domain that cannot be captured by tables via equations and 
membership assertions. Then we showed how one can use Maude, an efficient 
rewriting engine that implements membership equational logic, to execute such 



specifications and thus calculate the most concrete abstract type (or the least 
sort) of an expression. Building on the meta-capabilities of Maude, we further 
implemented a tool by which one can actually verify an abstract interpretation, 
given as a MEL specification, against equational or membership properties. Such 
a tool can be used to retrieve appropriate abstract interpretations from a library, 
to characterize the loss of information due to an abstraction, and to show refine- 
ments of abstract interpretations. 

We use this approach in a programming synthesis tool that generates data 
analysis C programs from stochastic specifications, in order to symbolically prove 
the conditions of algorithm schemas before they are applied. However, there is 
much interesting research to be done to prove the viability of our approach for a 
broader range of practical situations. For example, we don’t know at this stage 
how to represent infinite abstract interpretations, such as arbitrary integer in- 
tervals. Should the sort representation of the lattice be given up? Or should 
membership equational logic be extended to allow free generated algebras of 
sorts? What would regularity mean in such a context? Another important as- 
pect of abstract interpretations that we didn’t investigate is the computation of 
fixed points. Is there any relationship between regularity of MEL signatures and 
fixpoints? 

Acknowledgments: We thank Jose Meseguer and Steven Eker for encourage- 
ments and productive discussions. We also thank Steven Eker for providing us an 
alpha version of Maude 2.0 which uses the membership assertions in calculating 
the least sort of a term, so we could test our programs and claims. 
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A Some Implementation Details 

In this appendix we give a few hints on how we implemented the operation 
verify_on_ ; FModule FModule -> Bool that verifies an abstract interpretation 
against user defined properties, both represented as Maude modules. 

We first implemented some auxiliary operations on top of Maude’s meta- 
level. The code below is not executable; because of space limitations we replaced 
straightforward code by three dots: 

fmod META-AUXILIARY is including META-LEVEL . 


sort VarDeclTuple . 

op |_| : VarDeclSet -> VarDeclTuple . 


op getVarTuples : FModule VarDeclSet -> VarDeclTupleList . 
var M : FModule . var Var : VarDecl . var Vars : VarDeclSet . 
eq getVarTuples (M , none) = I none I . 
eq getVarTuples (M , Var Vars) 

= mergeVarDeclSet(getVarsFromVar (M, Var) .getVarTuples (M, Vars)) . 

op mergeVarDeclSet : VarDeclSet VarDeclTupleList -> VarDeclTupleList . 
op mergeVarDecl : VarDecl VarDeclTupleList -> VarDeclTupleList . 
var Ts : VarDeclTupleList . 
eq mergeVarDeclSet (none , Ts) = nil . 
eq mergeVarDeclSet (Var Vars, Ts) 

= mergeVarDecl (Var , Ts) mergeVarDeclSet (Vars , Ts) . 
eq mergeVarDecl (Var , nil) = nil . 

eq mergeVarDecl (Var , I Vars I Ts) = I Var Veirs I mergeVarDecl (Var , Ts) . 



op getVarsFromVar : FModule VarDecl -> VarDeclSet . 
vars V S : Qid . 

eq getVarsFromVar (M, var V : S .) 

= getVarsFromNameAndSorts(V, lesserSorts(M, S)) . 


endfm 

Notice the use of the builtin operation lesserSorts which takes a module and 
a sort name and gives a set of all smaller sorts. This set of sorts is then used 
to generate all possible combinations of declarations of variables, which will be 
subsequently used to calculate the least sorts of the terms involved in properties. 

The next module implements the main operation. It imports both the auxil- 
iary operations and a module defining warnings which we skipped; the warnings 
are currently some adhoc messages linked by a. 

fmod VERIFY-TYPE is including META-AUXILIARY + WARIIIG . 
op verify_on_ : FModule FModule -> Warnings . 
vars ABS , PROP : FModule . 
eq verify PROP on ABS = 

verifyEqns(getName(ABS) , getVarTuples(ABS, getVars(PROP) ) , getEqns(PROP)) 

Q verifyMbs(getName(ABS) , getVarTuples(ABS, getVars (PROP) ) , getMbs(PROP)) . 

op verifyEqns : Qid VeirDeclTupleList EquationSet -> Warnings . 

op verifyEqn : Qid VarDeclTupleList Equation -> Warnings . 

var Name : Qid . var Ts : VarDeclTupleList . var Vars : VarDeclSet . 

var Eqn : Equation . var Eqns : EquationSet . 

eq verifyEqns (Name , Ts, none) = ok . 

eq verifyEqns (Name , Ts, Eqn Eqns) = 

verifyEqn(Name , Ts, Eqn) Q verifyEqns (Name , Ts, Eqns) . 
eq verifyEqn(Neune , nil, Eqn) = finishedEqn(Eqn) . 
eq verifyEqn(Name , I Vars I Ts, Eqn) = 

(if leastSort(buildModule(Neune, Vars), lef tHandSide (Eqn) ) == 
leastSort(buildModule(Name, Vars), rightHandSide (Eqn) ) 
then ok else errorEqn? (Vars , Eqn) fi) Q verifyEqn (Name , Ts, Eqn) . 

op verifyMbs : Qid VarDeclTupleList MembAxSet -> Warnings . 
op verifyMb : Qid VarDeclTupleList MembAx -> Warnings . 
var Mb : MembAx . var Mbs : MembAxSet . 
eq verifyMbs (Name , Ts, none) = ok . 
eq verifyMbs (Name , Ts, Mb Mbs) = 

verifyMb (Name , Ts, Mb) Q verifyMbs (Name , Ts, Mbs) . 
eq verifyMb (Name , nil, Mb) = f inishedMb(Mb) . 
eq verifyMb (Name , I Vars I Ts, Mb) = 

(if sortLeq(buildModule (Name , Vars), 

leastSort (buildModule (Name , Vars), lef tHandSide (Mb) ) , 
rightHandSide (Mb) ) 

then ok else errorMb?(Vars , Mb) fi) Q verifyMb (Name , Ts, Mb) . 

endfm 


All equations and membership assertions are thoroughly tested on the specifica- 
tion representing the abstract interpretation. In the case of equations, the least 
sorts of both terms are calculated (using the builtin operation leastSort) and 
if different then a warning is issued. In the case of membership assertions, the 
least sort of the declared term is calculated and then compared with the declared 
sort (using the builtin operation sortLeq); if it is not smaller then a warning is 
generated. 



